Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Using super procedures for client code

The basic reason for using super procedures in a dynamic application is obvious: if your application object is fully data-driven, there is nowhere else to put it! There are a number of advantages to putting your custom code into a small, specialized procedure, while leaving all the standard behavior to dynamic Objects.

First, the compiled static SDO is a large procedure with a substantial amount of code providing a temp-table definition, query, and a number of update operations compiled specifically for that query and table. The internal procedures that provide custom validation logic are probably only a small percentage of the r-code generated for the SDO. You can greatly reduce the r-code that is deployed with your application by taking advantage of the dynamic SDO.

In addition, with your logic separate from the procedure that does the specific job of moving data back and forth between client and server, it can be executed more easily from elsewhere in your application, even when no SDO at all is involved. This is part of the reason why the SDO programming convention was modified to provide new validation hooks that can access an updated record by a more generally useful name of b_ plus the primary table name, rather than using the SDO-specific naming convention of calling it RowObjUpd.

The SDO’s logic procedure is just a specific example of a custom super procedure. It runs with some special wrapper code to make the updated record’s buffer available to the validation procedures, but otherwise it runs as a super procedure of the SDO and can contain any other code that is useful.

The same principle of writing super procedures also applies to other kinds of objects, including dynamic SmartDataViewers™. First, the r-code footprint of the deployed application is greatly reduced. Secondly, because the Viewers and their fields are represented in the Repository, this abstract definition of the Viewer is available to the UI Manager as a basis for a Web browser interface or other alternative interface. Having all the data in the Repository is beneficial in the following other ways as well:

To support various tools that need to know where fields are used.
To help you understand what objects contain what other objects.
To provide standard event behavior for a field no matter where it is used.

For these reasons, it is advisable to develop your applications with any required client-side logic in custom super procedures. In addition, other client-side objects like Browsers, as well as Windows, Folders, and Toolbars, are already dynamic, and the same techniques can apply to writing code to support these objects as well.